-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: move new client script #2333
Conversation
…dk-platform-java into feat/move-new-client-script
One option is add a release-please annotation so that the version num is the same as the latest release version. @suztomo what do you think this idea. |
Also I want to note that this is a temporary solution, we will add a new section for a new client library in the generation_config.yaml in the future. So specifying a generator version looks fine to me, and I would prefer us not to optimize too much for a temporary solution if it takes more than like 30 minutes. |
I agree that Release Please is overkill for this work. Here is the shell script to get the version:
|
Thanks for the help. |
versioned_path=versioned_proto_path, | ||
) | ||
repo_root_dir = Path(f"{sys.path[0]}/../../").resolve() | ||
generator_version = subprocess.check_output( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The version of generator is now parsed from WORKSPACE. This is a temporary fix so that release manager doesn't need to specify this value.
The plan is to use the version in config file later.
|
||
s.remove_staging_dirs() | ||
{% if should_include_templates %}java.common_templates(monorepo=True, {% if template_excludes %}excludes=[ | ||
{%- for exclude in template_excludes %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change template so that update_owlbot_postprocessor_config.sh
is not needed.
templates.render( | ||
template_name="bom_pom.xml.j2", | ||
output_name=f"{artifact_id}-bom/pom.xml", | ||
repo=repo_metadata["repo"], | ||
name=name, | ||
modules=modules, | ||
main_module=main_module, | ||
monorepo=monorepo, | ||
monorepo_version=monorepo_version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change the template so that we can remove set_parent_pom.sh
.
@@ -386,11 +399,12 @@ def main(versions_file, monorepo): | |||
module=required_dependencies[path], | |||
parent_module=parent_module, | |||
main_module=main_module, | |||
monorepo=monorepo, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change the proto pom template to remove consolidate_config.sh
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking forward to see the observations that it works for shopping CSS.
Steps to regenerate shopping CSS:
|
|
|
That looks good to me. Thank you. |
@@ -477,52 +493,57 @@ def main(versions_file, monorepo): | |||
update_bom_pom(f"{artifact_id}-bom/pom.xml", modules) | |||
elif artifact_id+"-bom" not in excluded_poms_list: | |||
print("creating missing bom pom.xml") | |||
monorepo_version = __get_monorepo_version(versions_file) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may missed this in earlier reviews, can you please remind me why we need to get monorepo_version
now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to generate the pom.xml in *-bom
without using a repo-level post processing script (set_parent_pom.sh
in this case) and run mvn fmt:format
after the pom generation.
This requires to know the current version of gapic-libraries-bom
and google-cloud-jar-parent
, which is the same as the monorepo version.
In this PR:
new-client.py
from google-cloud-java, because we will be using new-client.py to other use cases than google-cloud-java repository, such as self-service client library generation.library_generation/repo-level-postprocess
To verify
new-client.py
:google-cloud-java
.library_generation
folder to root directory ofgoogle-cloud-java
.google-cloud-java
, remove a newly added module, e.g.,java-cloudquotas
(PR).git status
andgit diff
to verify the difference.This is part of milestone 2 of hermetic build project plan.
Note that I didn't test the script against split repositories because the main use case of this script is to generate a module in google-cloud-java.